Fencing of resources allocated to non-cooperative client computers

ABSTRACT

Techniques are provided for processing an Input/Output (I/O) request in which an identification message is received from a client computer. It is determined whether the client computer is a rogue client based on whether a current operations record exists for the client computer.

CROSS REFERENCE TO RELATED APPLICATION

This application is a divisional application of and claims the benefitof “FENCING OF RESOURCES ALLOCATED TO NON-COOPERATIVE CLIENT COMPUTERS”,having application Ser. No. 10/851,452, filed May 20, 2004, the entirecontents of which is incorporated herein by reference.

BACKGROUND

1. Field

Implementations of the invention relate to fencing of resourcesallocated to non-cooperative client computers.

2. Description of the Related Art

In a distributed Input/Output (I/O) environment, such as a Storage AreaNetwork (SAN), a lock granting server computer may provide distributedlocking techniques to enable a client computer to gain exclusive/sharedaccess to data blocks in a storage area. A rogue client may be describedas a client computer that has lost connectivity with the lock grantingserver computer while the client computer holds an exclusive lock to oneor more data blocks. The loss of connectivity may occur due to a problemat the client computer (e.g., a problem with a device driver) or due toa problem with the environment (e.g., a problem with the SAN).

For example, a lock granting server computer may give a first clientcomputer an exclusive lock to data blocks to fulfill an I/O request(e.g., a copy operation). If the first client computer does not fulfillthe I/O request within a specified period of time, the first clientcomputer is deemed to be a rogue client. The lock granting servercomputer may then revoke the exclusive lock for the first computer andmay allow a second client computer to write to the data blocks. In thiscase, if the rogue client cannot be contacted by the lock grantingserver computer, the rogue client may continue to write to the datablocks protected by the exclusive lock, and, thus, may overwrite datathat the second client computer has written to the same data blocks.

Conventional systems may provide host-based hardware solutions orstorage-based solutions to the rogue client problem. With the host-basedhardware solutions, a special processor is installed on the clientcomputer and has access to a network. The lock granting server computeris able to send a message to the processor instructing the processor topower cycle (i.e., shut down) a rogue client. An example of this is anIBM® Remote Supervisor Adapter (RSA) card (available for purchase fromInternational Business Machines, Corporation). With RSA cards, the lockgranting server computer and the client computer each have RSA cardsthat communicate with each other. The lock granting server computernotifies its RSA card to send a signal to the client computer RSA cardto shut down the client computer. With host-based hardware solutions, ifthe rogue client problem occurred due to problems with a device driverat the rogue client, shutting down and restarting the client computermay solve the problem. On the other hand, if the rogue client problemoccurred because the client computer was unable to communicate with theserver computer due to a SAN failure, then, the hardware-based solutionsdo not solve the rogue client problem.

With storage-based solutions, high end storage systems support featuresthat allow the lock granting server computer to send the storage systema message instructing the storage system to ignore I/O requests from aspecific rogue client. An example of this is dynamic Logical Unit Number(LUN) masking in a SAN. A LUN is a unique number that may identify aspecific disk. With dynamic LUN masking, the storage subsystem may benotified to ignore I/O requests from a particular client for aparticular LUN. Storage-based solutions address situations in which therogue client problem occurred due to a SAN failure, but do not addresssituations in which the rogue client problem occurred due to a failureof a device driver at the client computer.

Thus, notwithstanding existing techniques, there is a continued need inthe art to provide better techniques for client computer failurerecovery.

SUMMARY OF THE INVENTION

Provided are an article of manufacture, system, and method forprocessing an Input/Output (I/O) request. At least one data block isallocated for use in completing the I/O request. A current operationsrecord is stored for the I/O request. It is determined whether the I/Orequest has been completed within a specified period of time. Inresponse to determining that the I/O request has not been completedwithin the specified period of time, the allocated at least one datablock is fenced.

Provided are an article of manufacture, system, and method forprocessing an Input/Output (I/O) request in which an identificationmessage is received from a client computer. It is determined whether theclient computer is a rogue client based on whether a current operationsrecord exists for the client computer.

BRIEF DESCRIPTION OF THE DRAWINGS

Referring now to the drawings in which like reference numbers representcorresponding parts throughout:

FIG. 1 illustrates a computing environment in accordance with certainimplementations of the present invention.

FIG. 2 illustrates logic implemented in a data block allocation processfor allocating data blocks in accordance with certain implementations ofthe present invention.

FIG. 3 illustrates logic implemented in a data block allocation processfor revoking access to data blocks in accordance with certainimplementations of the present invention.

FIG. 4 illustrates logic implemented in a client identification processfor client computer identification in accordance with certainimplementations of the present invention.

FIG. 5 illustrates an architecture of a computer system that may be usedin accordance with certain implementations of the present invention.

DETAILED DESCRIPTION

In the following description, reference is made to the accompanyingdrawings which form a part hereof and which illustrate severalimplementations of the invention. It is understood that otherimplementations may be utilized and structural and operational changesmay be made without departing from the scope of the invention.

FIG. 1 illustrates a computing environment in accordance with certainimplementations of the present invention. A client computer 100 isconnected via, for example, a network 190 to a server computer 120. Theclient computer 100 may comprise any computing device known in the art,such as a server, mainframe, workstation, personal computer, hand heldcomputer, laptop telephony device, network appliance, etc. The network190 may comprise any type of network, such as, for example, a StorageArea Network (SAN), a Local Area Network (LAN), Wide Area Network (WAN),the Internet, an Intranet, etc. When the client computer 100 receives arequest to perform a task from the server computer 120, the clientcomputer 100 may be said to be acting as a server computer, while theserver computer 120 may be said to be acting as a client computer forthe purpose of this request. Regardless of whether the client computer100 is acting as a client or a server computer, the references herein to“client computer” refer to client computer 100, unless otherwiseindicated. Similarly, regardless of whether the server computer 120 isacting as a client or server computer, the references herein to “servercomputer” refer to server computer 120, unless otherwise indicated.

The client computer 100 includes system memory 102, which may beimplemented in volatile and/or non-volatile devices, and one or moreCentral Processing Units (CPUs) 106. One or more client applications 104may reside in system memory 102 for execution by a Central ProcessingUnit (CPU) 106.

The server computer 120 includes system memory 122, which may beimplemented in volatile and/or non-volatile devices and one or moreCentral Processing Units (CPUs) 130. One or more server applications124, a client identification process 125, and a data block allocationprocess 126 may reside in system memory 122 for execution by a CentralProcessing Unit 130. Also, one or more current operations records 142may reside in a persistent data store 140. In certain implementations,the data store 140 may be part of the storage area 180, and inalternative implementations, the data store 140 may be separate from thestorage area 180. The data block allocation process 126 uses the currentoperations records 142 to later determine whether a client computer 100has become a rogue client. In certain implementations, the currentoperations records are maintained for client computers that have beenallocated data blocks to complete I/O requests and are kept for rogueclients that have not completed their I/O requests.

The client computer is also connected directly or indirectly (e.g., viaa network (not shown)) to a storage area 180. The storage area mayinclude a Storage Area Network (SAN), Direct Access Storage Devices(DASDs), Just a Bunch of Disks (JBOD), Redundant Array of IndependentDisks (RAID). The storage area 180 includes data blocks. The data blocksmay form multiple volumes, such as Volume A 182 and Volume B 184 (i.e.,each volume may include one or more data blocks).

The server computer 120 may either not be physically connected to thestorage area 180 or the server computer 120 may be physically connectedto the storage area but may be unable to access the storage area 180(e.g., due to zoning, business policies, etc.).

FIG. 2 illustrates logic implemented in a data block allocation process126 for allocating data blocks in accordance with certainimplementations of the present invention. Control begins at block 200with the data block allocation process 126 allocating one or more datablocks to the client computer 100 for use in completing an I/O request.For example, the server computer 120 may wish to copy data blocks fromVolume A 182 to Volume B 184, but, because the server computer 120 doesnot have access to storage area 180, the server computer 120 may requestthe client computer 100 to perform the copy operation. The servercomputer 120 allocates the data blocks and grants the client computer100 exclusive access to those data blocks.

In block 202, the data block allocation process 126 stores a currentoperations record. The current operations record is persistently storedand contains, for example, a persistent name for the client computer100, addresses of the allocated data blocks, and a timestamp. The datablock allocation process 126 then notifies the client computer 100 thatthe client computer 100 can use the allocated data blocks to completethe I/O request.

Thus, prior to granting a client computer 100 permission to write to apreviously unallocated area of storage, the data block allocationprocess 126 persistently stores a current operations record stating thedata blocks it is granting permission to write, the client it is givingpermission to write, and a timestamp. The data block allocation process126 then grants permission to the client computer 100. If at a latertime that permission is to be revoked, in certain implementations, anotice is sent to the client computer 100, and, if the client computer100 does not respond to the notice within a specified period of time,the permission is revoked and the affected data blocks are fenced off byleaving them marked as allocated.

By leaving the blocks marked as allocated, the blocks cannot bereallocated for some other purpose. If they were reallocated, it ispossible that the data blocks may be overwritten at a later time by therogue client, causing data corruption.

The next time the client computer identifies with the data blockallocation process 126, the data block allocation process 126 checks tosee whether the client computer is considered a rogue client. If so, thedata block allocation process 126 sends the client a message to cancelany pending write operations. If a response is successfully received,then the client computer 100 is no longer considered rogue. The datablock allocation process 126 removes the current operations recordspertaining to the client computer 100 and deallocates the affected datablocks.

FIG. 3 illustrates logic implemented in a data block allocation process126 for revoking access to data blocks in accordance with certainimplementations of the present invention. Control begins at block 300with the data block allocation process 126 determining whether theclient computer 100 response timed out. That is, the data blockallocation process 126 determines whether the client computer 100completed the I/O request within a specified period of time. Completingthe I/O request includes the client computer 100 sending a response tothe server computer 120 within the specified period of time. If theserver computer 120 does not receive a response within the specifiedperiod of time, the server computer 120 conservatively assumes that theI/O request was not completed. From block 302, if the response timedout, processing continues to block 304, otherwise, processing continuesto block 306. If the response times out, in block 304, the data blockallocation process 126 designates the client computer 100 as a rogueclient. This means that the client computer 100 did not complete the I/Orequest within the specified period of time. If the response does nottime out (i.e., the client computer 100 completed the I/O request withinthe specified period of time), in block 306, the data block allocationprocess 126 removes the current operations record from storage.

In certain implementations, the data block allocation process 126 sendsa notice to the client computer 100 that access to the previouslyallocated data blocks is being revoked. If the client computer 100 doesnot respond within a specified period of time to the notice, the datablock allocation process 126 declares the client computer 100 to be arogue client, leaving behind the current operations record that wascreated for the allocated data blocks.

In certain implementations, the client computer periodically sends arequest to the data block allocation process 126 to continue to haveaccess to the allocated data blocks (which request is also referred toas a request to “renew a lease” for the allocated data blocks). If thedata block allocation process 126 wants to revoke access to the datablocks, the data block allocation process 126 does not return a messageto the client computer 100 that the lease is being renewed. In thismanner, the client computer 100 automatically determines that the leasehas not been renewed.

FIG. 4 illustrates logic implemented in a client identification process125 for client computer identification in accordance with certainimplementations of the present invention. Control begins at block 400with the client identification process 125 receiving a clientidentification message from the client computer 100. The client computer100 sends the client identification message to create a connection tothe server computer 120 for communicating with the server computer 120.In block 402, the client identification process 125 determines whetherthe client computer 100 is a rogue client. The determination is made bydetermining whether a current operations record exists for the clientcomputer 100. If a current operations record exists for a clientcomputer 100 that is attempting to create a new connection with theserver computer 120, then the client identification process 125determines that this client computer 100 did not complete an I/O requestduring a previous connection, and so the current operations records hasbeen persistently maintained for the client computer 100.

If the client computer 100 is a rogue client, processing continues toblock 404, otherwise, processing continues to block 412. In block 404,the client identification process 125 sends a cancel I/O request messageto the rogue client. In block 406, the client identification process 125determines whether a response has been received from the client computer100 for the cancel I/O request message. If a response has been received,processing continues to block 408, otherwise, processing continues toblock 414. In block 408, the client identification process 125deallocates the data blocks previously allocated to the client computer100. That is, if the client computer 100 acknowledges the cancel I/Orequest message, the client identification process 125 recognizes thatthe data blocks will not be overwritten by the rogue client and is ableto allocate them for another operation. In block 410, the clientidentification process 125 removes the current operations record for theclient computer 100. From block 410, processing continues to block 412.

In block 412, the client identification process 125 accepts anidentification message from the client computer 100, which enables theclient computer 100 to communicate further with the server computer 120.

In block 414, because a response was not received from the rogue clientfor the cancel I/O request message, the identification message isrejected. Thus, the rogue client cannot communicate with the servercomputer further until the current operations record for that rogueclient has been removed. In certain implementations, the currentoperations records are periodically removed (e.g., every 24 hours) sothat if a rogue client has, for example, a persistent hardware failureor no longer exists, the allocated data blocks may later be reallocated.This typically occurs after some period of time has elapsed sincecreation of the current operations record (e.g., the current operationsrecord may be removed 24 hours after being created).

Thus, when the client identification process 125 receives an identifyrequest from a client computer, it checks to see if it has a currentoperations record for that client computer 100. If none exist, theclient computer identify request is accepted. If there are one or morecurrent operations records for the client computer, then the clientidentification process 125 sends a cancel I/O request message to theclient computer. If the client computer responds successfully, thatmeans the client computer is no longer performing I/O with those datablocks and it is safe for the data blocks to be reused. In this case,the data blocks are deallocated, the current operations records for therogue client are removed, and the identify request is accepted.

Implementations of the invention are applicable to various scenarios.Some example scenarios will be described herein merely for illustration,and it is not intended that the implementations be limited to theexample scenarios.

In one example scenario, a remote copy of data is performed using aclient computer 100 as a proxy. In this case, the server computer 120desires to copy data from one range of data blocks to another range ofdata blocks. In cases in which the server computer 120 does not haveaccess to the required Logical Unit Numbers of the data blocks (e.g.,due to LUN masking), the server computer 120 instructs a client computer100 to perform the copy operation.

The data block allocation process 126 at the server computer 120allocates a target range for the data blocks and stores the name of theclient and the target data blocks persistently. The data blockallocation process 126 then sends a message to the client computer 100to copy data from source data blocks to the allocated target datablocks. If the client computer 100 response does not time out, then theI/O request has been successfully completed and the allocated datablocks are not deallocated. If the client computer 100 response timesout, then the client computer 100 is considered a rogue client. Whilethe client computer 100 is considered a rogue client, the target datablocks are not used. Once the client computer 100 identifies itself, acancel message is sent to the client computer 100. If the clientcomputer 100 responds successfully, then the target data blocks aredeallocated (i.e., because the copy operation previously failed) and thepersistent current operations record is removed.

Certain log-based file systems perform write operations as a newallocation followed by a copy of the data. Therefore, implementations ofthe invention are applicable to such log-based files systems that allowfor distributed I/O.

In a second example scenario, a remote write of data is performed usinga client computer 100 as a proxy. In this case, the server computer 120directs a client computer 100 to write a particular set of data to oneor more data blocks. The data block allocation process 126 at the servercomputer 120 allocates a target range for the data blocks and stores thename of the client computer 100 and the target data blocks persistently.The data block allocation process 126 then sends a message to the clientcomputer 100 to write data to the target data blocks, and the messagecontains the data to be written. If the client computer 100 responsedoes not time out, then the I/O request has been successfully completedand the allocated data blocks are not deallocated. If the clientcomputer 100 response times out, then the client computer 100 isconsidered a rogue client. While the client computer 100 is considered arogue client, the target data blocks are not used. Once the clientcomputer 100 identifies itself, a cancel message is sent to the clientcomputer 100. If the client computer 100 responds successfully, then thetarget data blocks are deallocated (i.e., because the write operationpreviously failed) and the persistent current operations record isremoved.

In a third example scenario, implementations of the invention may beextended for the case in which the data to be written to a data block isthe same (i.e., repeated writes of the data block are idempotent). Inthis case, implementations deallocate the data blocks after a writetimes out because a future write to the same block writes the same setof contents.

In the third example scenario, a Logical Unit Number is written to adisk label. The server computer 120 labels a disk by writing a smallrecord at a fixed offset on the disk. The record contains informationthat uniquely identifies the disk as belonging to the server computer120. Other client computers and server computers in the distributed I/Oenvironment scan disks they have access to. If the client computer orserver computer recognizes the label on the disk as valid, then thatcomputer assumes it can use the disk.

Implementations of the invention enable safely labeling a LUN on a disklabel using a client computer 100 as a proxy. If an administratordirects the server computer 120 to write a label to a particular disk,the server computer 120 checks the current operations records todetermine whether a label has already been generated for the disk. If alabel has not already been generated, the server computer 120 generatesa unique label for the disk and stores the label along with the currentoperations record (e.g., the server computer is storing the diskidentifier, unique label, and client name persistently). The servercomputer 120 then sends a message to the client computer 100 to writethe label. If the client computer 100 response times out, the servercomputer 120 assumes that the write request has failed. However, sincethe write is idempotent (i.e., the same label will be written by asubsequent write label operation), the server computer 120 allows thesame disk to be labeled by another client computer, even while the firstclient computer is still considered to be a rogue client.

Thus implementations provide distributed failure recovery in adistributed Input/Output (I/O) environment. Certain implementationsaddress a subset of the “rogue” client problem. Implementations of theinvention differ from the host-based hardware solutions because theimplementations do not require special hardware to be installed on anyof the clients. Implementations of the invention differ from thestorage-based solutions because the implementations do not depend onhaving special storage systems.

Certain implementations of the invention address a subset of the rogueclient problem for the cases in which the data blocks that are to beallocated were previously unallocated, and, therefore, their previouscontents do not matter.

IBM is a registered trademark or common law mark of InternationalBusiness Machines, Corporation in the United States and/or othercountries.

Additional Implementation Details

The described embodiments may be implemented as a method, apparatus orarticle of manufacture using programming and/or engineering techniquesto produce software, firmware, hardware, or any combination thereof. Theterms “article of manufacture” and “circuitry” as used herein refers toa state machine, code or logic implemented in hardware logic (e.g., anintegrated circuit chip, Programmable Gate Array (PGA), ApplicationSpecific Integrated Circuit (ASIC), etc.) or a computer readable medium,such as magnetic storage medium (e.g., hard disk drives, floppy disks,tape, etc.), optical storage (CD-ROMs, optical disks, etc.), volatileand non-volatile memory devices (e.g., EEPROMs, ROMs, PROMs, RAMs,DRAMs, SRAMs, firmware, programmable logic, etc.). Code in the computerreadable medium is accessed and executed by a processor. When the codeor logic is executed by a processor, the circuitry may include themedium including the code or logic as well as the processor thatexecutes the code loaded from the medium. The code in which embodimentsare implemented may further be accessible through a transmission mediaor from a file server over a network. In such cases, the article ofmanufacture in which the code is implemented may comprise a transmissionmedia, such as a network transmission line, wireless transmission media,signals propagating through space, radio waves, infrared signals, etc.Thus, the “article of manufacture” may comprise the medium in which thecode is embodied. Additionally, the “article of manufacture” maycomprise a combination of hardware and software components in which thecode is embodied, processed, and executed. Of course, those skilled inthe art will recognize that many modifications may be made to thisconfiguration, and that the article of manufacture may comprise anyinformation bearing medium known in the art.

The logic of FIGS. 2-4 describes specific operations occurring in aparticular order. In alternative implementations, certain of the logicoperations may be performed in a different order, modified or removed.Moreover, operations may be added to the above described logic and stillconform to the described implementations. Further, operations describedherein may occur sequentially or certain operations may be processed inparallel, or operations described as performed by a single process maybe performed by distributed processes.

The illustrated logic of FIGS. 2-4 may be implemented in software,hardware, programmable and non-programmable gate array logic or in somecombination of hardware, software, or gate array logic.

Also, various processing has been described as possibly occurring within“a specified period of time”, but the specified periods of time forvarious processing may be different. For example, the specified periodof time for a client computer 100 to complete an I/O request may be adifferent amount of time than the specified period of time for theclient computer 100 to respond to a notice from the server computer 120.

FIG. 5 illustrates an architecture of a computer system that may be usedin accordance with certain implementations of the present invention.Client computer 100 and/or server computer 120 may implement computerarchitecture 500. The computer architecture 500 may implement aprocessor 502 (e.g., a microprocessor), a memory 504 (e.g., a volatilememory device), and storage 510 (e.g., a non-volatile storage area, suchas magnetic disk drives, optical disk drives, a tape drive, etc.). Anoperating system 505 may execute in memory 504. The storage 510 maycomprise an internal storage device or an attached or network accessiblestorage. Computer programs 506 in storage 510 may be loaded into thememory 504 and executed by the processor 502 in a manner known in theart. The architecture further includes a network card 508 to enablecommunication with a network. An input device 512 is used to provideuser input to the processor 502, and may include a keyboard, mouse,pen-stylus, microphone, touch sensitive display screen, or any otheractivation or input mechanism known in the art. An output device 514 iscapable of rendering information from the processor 502, or othercomponent, such as a display monitor, printer, storage, etc. Thecomputer architecture 500 of the computer systems may include fewercomponents than illustrated, additional components not illustratedherein, or some combination of the components illustrated and additionalcomponents.

The computer architecture 500 may comprise any computing device known inthe art, such as a mainframe, server, personal computer, workstation,laptop, handheld computer, telephony device, network appliance,virtualization device, storage controller, etc. Any processor 502 andoperating system 505 known in the art may be used.

The foregoing description of implementations of the invention has beenpresented for the purposes of illustration and description. It is notintended to be exhaustive or to limit the implementations of theinvention to the precise form disclosed. Many modifications andvariations are possible in light of the above teaching. It is intendedthat the scope of the implementations of the invention be limited not bythis detailed description, but rather by the claims appended hereto. Theabove specification, examples and data provide a complete description ofthe manufacture and use of the composition of the implementations of theinvention. Since many implementations of the invention can be madewithout departing from the spirit and scope of the implementations ofthe invention, the implementations of the invention reside in the claimshereinafter appended or any subsequently-filed claims, and theirequivalents.

1. A method for processing an Input/Output (I/O) request, comprising:receiving an identification message from a client computer; anddetermining whether the client computer is a rogue client based onwhether a current operations record exists for the client computer. 2.The method of claim 1, further comprising: in response to determiningthat the client computer is a rogue client, sending a cancel I/O requestmessage to the client computer; and determining whether a response wasreceived for the cancel I/O request message.
 3. The method of claim 2,further comprising: in response to determining that the response wasreceived for the cancel I/O request message, deallocating the allocatedat least one data block; and removing the current operations record forthe cancelled I/O request; and in response to determining that theresponse was not received for the cancel I/O request message, rejectingthe identification message.
 4. An article of manufacture for processingan Input/Output (I/O) request, wherein the article of manufacturecomprises a computer readable medium storing instructions, and whereinthe article of manufacture is operable to: receive an identificationmessage from a client computer; and determine whether the clientcomputer is a rogue client based on whether a current operations recordexists for the client computer.
 5. The article of manufacture of claim4, wherein the article of manufacture is further operable to: inresponse to determining that the client computer is a rogue client, senda cancel I/O request message to the client computer; and determinewhether a response was received for the cancel I/O request message. 6.The article of manufacture of claim 5, wherein the article ofmanufacture is further operable to: in response to determining that theresponse was received for the cancel I/O request message, deallocate theallocated at least one data block; and remove the current operationsrecord for the cancelled I/O request; and in response to determiningthat the response was not received for the cancel I/O request message,rejecting the identification message.
 7. A system for processing anInput/Output (I/O) request, comprising: circuitry operable to: receivean identification message from a client computer; and determine whetherthe client computer is a rogue client based on whether a currentoperations record exists for the client computer.
 8. The system of claim7, wherein the circuitry is further operable to: in response todetermining that the client computer is a rogue client, send a cancelI/O request message to the client computer; and determine whether aresponse was received for the cancel I/O request message.
 9. The systemof claim 8, wherein the circuitry is further operable to: in response todetermining that the response was received for the cancel I/O requestmessage, deallocate the allocated at least one data block; and removethe current operations record for the cancelled I/O request; and inresponse to determining that the response was not received for thecancel I/O request message, rejecting the identification message.